<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
    <title>Atomicity</title>
    <link rel="stylesheet" href="gettingStarted.css" type="text/css" />
    <meta name="generator" content="DocBook XSL Stylesheets V1.73.2" />
    <link rel="start" href="index.html" title="Berkeley DB Programmer's Reference Guide" />
    <link rel="up" href="transapp.html" title="Chapter 12.  Berkeley DB Transactional Data Store Applications" />
    <link rel="prev" href="transapp_put.html" title="Recoverability and deadlock handling" />
    <link rel="next" href="transapp_inc.html" title="Isolation" />
  </head>
  <body>
    <div xmlns="" class="navheader">
      <div class="libver">
        <p>Library Version 12.1.6.2</p>
      </div>
      <table width="100%" summary="Navigation header">
        <tr>
          <th colspan="3" align="center">Atomicity</th>
        </tr>
        <tr>
          <td width="20%" align="left"><a accesskey="p" href="transapp_put.html">Prev</a> </td>
          <th width="60%" align="center">Chapter 12.  Berkeley DB Transactional Data Store Applications </th>
          <td width="20%" align="right"> <a accesskey="n" href="transapp_inc.html">Next</a></td>
        </tr>
      </table>
      <hr />
    </div>
    <div class="sect1" lang="en" xml:lang="en">
      <div class="titlepage">
        <div>
          <div>
            <h2 class="title" style="clear: both"><a id="transapp_atomicity"></a>Atomicity</h2>
          </div>
        </div>
      </div>
      <p>
        The second reason listed for using transactions was
        <span class="emphasis"><em>atomicity</em></span>. Atomicity means that
        multiple operations can be grouped into a single logical
        entity, that is, other threads of control accessing the
        database will either see all of the changes or none of the
        changes. Atomicity is important for applications wanting to
        update two related databases (for example, a primary database
        and secondary index) in a single logical action. Or, for an
        application wanting to update multiple records in one database
        in a single logical action.
    </p>
      <p>
        Any number of operations on any number of databases can be
        included in a single transaction to ensure the atomicity of
        the operations. There is, however, a trade-off between the
        number of operations included in a single transaction and both
        throughput and the possibility of deadlock. The reason for
        this is because transactions acquire locks throughout their
        lifetime and do not release the locks until commit or abort
        time. So, the more operations included in a transaction, the
        more likely it is that a transaction will block other
        operations and that deadlock will occur. However, each
        transaction commit requires a synchronous disk I/O, so
        grouping multiple operations into a transaction can increase
        overall throughput. (There is one exception to this: the
        <a href="../api_reference/C/envset_flags.html#set_flags_DB_TXN_WRITE_NOSYNC" class="olink">DB_TXN_WRITE_NOSYNC</a> and <a href="../api_reference/C/envset_flags.html#envset_flags_DB_TXN_NOSYNC" class="olink">DB_TXN_NOSYNC</a> flags cause
        transactions to exhibit the ACI (atomicity, consistency and
        isolation) properties, but not D (durability); avoiding the
        write and/or synchronous disk I/O on transaction commit
        greatly increases transaction throughput for some
        applications.)
    </p>
      <p>
        When applications do create complex transactions, they often
        avoid having more than one complex transaction at a time
        because simple operations like a single <a href="../api_reference/C/dbput.html" class="olink">DB-&gt;put()</a> are unlikely
        to deadlock with each other or the complex transaction; while
        multiple complex transactions are likely to deadlock with each
        other because they will both acquire many locks over their
        lifetime. Alternatively, complex transactions can be broken up
        into smaller sets of operations, and each of those sets may be
        encapsulated in a nested transaction. Because nested
        transactions may be individually aborted and retried without
        causing the entire transaction to be aborted, this allows
        complex transactions to proceed even in the face of heavy
        contention, repeatedly trying the suboperations until they
        succeed.
    </p>
      <p>
        It is also helpful to order operations within a transaction;
        that is, access the databases and items within the databases
        in the same order, to the extent possible, in all
        transactions. Accessing databases and items in different
        orders greatly increases the likelihood of operations being
        blocked and failing due to deadlocks.
    </p>
    </div>
    <div class="navfooter">
      <hr />
      <table width="100%" summary="Navigation footer">
        <tr>
          <td width="40%" align="left"><a accesskey="p" href="transapp_put.html">Prev</a> </td>
          <td width="20%" align="center">
            <a accesskey="u" href="transapp.html">Up</a>
          </td>
          <td width="40%" align="right"> <a accesskey="n" href="transapp_inc.html">Next</a></td>
        </tr>
        <tr>
          <td width="40%" align="left" valign="top">Recoverability and deadlock handling </td>
          <td width="20%" align="center">
            <a accesskey="h" href="index.html">Home</a>
          </td>
          <td width="40%" align="right" valign="top"> Isolation</td>
        </tr>
      </table>
    </div>
  </body>
</html>
